Electronic screen module allows us to get detailed information about a user's display hardware.
This includes screen dimensions, pixel ratio, cursor position or even events relating to screen changes.
Now, as with a handful of other node modules, the screen module requires a slightly different approach
to being used, being that the app must be ready for this event here on which we also create the main
window.
We can, however, require the module immediately.
So let's do that from electron screen and then in that create window function that fires as a result
of the app being ready, I log it out.
I have my terminal window on the desktop for this lesson.
So I'll also move the main window to the left slightly, say X 100 and Y also 100 that you do save.
And there we see that module with all its methods in the terminal, take note that this module consists
mainly of getter and setter functions, no properties, this being a screen dimensions cursor position
and pretty much anything related to a display can change at any time.
So getting properties for a display will always be retrieved via a function, ensuring its current step
one then is actually getting a reference to the user's displays in the docs.
Scroll down to methods.
Yeah, we have this get all displays method to get an array of all the connected displays or get primary
display, which we'll see in a minute.
For now, though, I log out my displays in the terminal with screen dot get all displays.
Which locks out an array with two display objects being as I have my laptops both in display and an
external monitor.
So two displays in total.
And as before, when we retrieved thumbnail images of these displays, the first display object in this
array is always the designated primary display, in my case being my external monitor, having a size
of 10 by 1920 with a scale factor of two, meaning the size not to be confused with the resolution is
scaled up to twice its size.
So a four key display, the size and bound properties being extremely useful for knowing exactly what
sort of real estate a user's working with.
I'll demonstrate a sign these displays to a variable.
Then to get a better understanding of my display layout, I log out a template, literal or interpolated
string displays, zero being my primary display, dot size, dot width by or times the height.
Copy this.
Changing width to height.
Safe to check.
There, as before tonight, by 1920, my primary display size.
At the secondary display of duplicate, this changing to the second display or index, one size being
the first part of what we need to understand display layout, the second being the bounds or position
duplicate this logging the primary displays x coordinate with bound dot X and bound dot.
Why change this X to a comma?
Copy the line for the second display.
Displays won.
So size and bounds of the primary display first and then the same for the secondary display save.
They're 19, 20 by 10 and starting at coordinates zero zero and 14, 40 by 900 for my 13 inch laptop
display, starting on the x axis at 19, 20 and Y of 180.
This might not make much sense right now, but if I bring my display arrangement into view, we can
plot this to better understand these properties.
My primary display being this one here and my secondary display, the smaller one on the right.
So the display sizes are pretty straightforward.
1920 by 10 and 14, 40 by 900, the X and Y coordinates being what helps us understand how to apply
these sizes and get the layout.
The starting point is always relative to the primary display, X zero and Y zero at the top left corner.
Then relative to those points, the secondary displays X coordinate being 19 20 equal to the width of
the primary display and its Y coordinate, 180 being the height offset as per this arrangement density
minus 900.
Should this have been my designated primary display?
Zero and Y zero would have been here with this display having an X coordinate of minus nine 20 being
negative to the X axis and a Y coordinate of minus 180.
So all based on a simple x y grid relative to the primary display.
Another very useful feature of the screen module is the ability to detect changes in display arrangements
in the event section.
We have the ability to listen for displays being added removed or any display metrics changing.
In my case, for example, having an external monitor as my primary display.
Should I unplug that monitor?
Both this display removed and the display matrix changed event would fire as my laptop display would
then become my primary display.
Let's see this event.
Listen on the screen module screen on for display metrics changed pass a callback which provides us
with the event object, the display object of the affected display and an array of metrics that changed.
I love those changes out.
Then back in my display preferences, I'll rotate my primary display by 90 degrees.
Revert the change.
And there we have it, a couple of logs for the initial rotation, this might look different for your
particular operating system or even version of operating system, and then a second set of logs when
reverting the rotation, telling us that the bounce changed so that X Y coordinates of the primary display
being the one I rotated the work area, which is the operating systems calculated screen area.
So minus the task bars and other static UI elements.
And of course, the rotation.
So we can pretty much be aware at all times of what's going on with the splays.
The screen module will also allow us to retrieve screen based information such as the mouse cursor position.
Cursor position can be a very valuable bit of information if, say, a particular message is received
from the renderer process, something we'll see later in the course.
And when getting the position of the user's cursor, that position is, of course, directly relative
to the screen size and bounds we've been working with.
I'll demonstrate a simple example for now.
I'll just add a running interval set interval with a callback to execute every 100 milliseconds.
And in that callback log out screen dot, get cursor screen point.
Save.
And immediately we see the cursor positions, X and Y coordinates continuously being locked out with
zero zero being right up in the top left of my primary display, as we saw earlier in the screen layouts.
OK, so all of that should pretty much explain how the screen module calculates screen real estate.
The last thing I want to demonstrate then is a very simple example of how we might use this size and
bounce parameters.
For example, let's see how to create a browser window that folds exactly half of the primary display.
So far, we've just been accessing the primary display as the first element in the displays array,
but we also have a method to do this for us.
I'll get a reference to my primary display assigning to primary display screen DOT, get primary display,
copy this variable.
And now, as mentioned, we can use this display objects dimensions to create a browser window that
follows exactly half the screen, said Main Windows X coordinate two primary display dot bound Dot X..
So the top left corner of the display y two primary display dot bound dot y the width to half of the
primary display primary display.
Size dot width divide by two and the full height primary display.
Dot size.
Dot height.
And there we get a perfectly sized main window filling exactly half of the display.